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AUTOMATED SALES COMMISSION CALCULATION METHODS AND SYSTEMS 

Field of the Invention 

[0001] Methods and systems for calculating sales commissions and, more particularly, 

methods and systems for calculating sales commissions based on business rules stored in tables. 

Background of the Invention 
[0002] Fig. 1 is a schematic diagram of an example of a credit and debit card transaction 

system 10 in the United States. When a credit or debit card transaction is processed, data 
required to effectuate (or settle) the transaction is entered in a terminal, a request for 
authorization to complete the transaction (based on the transaction data) is generated, an 
authorization is either granted or denied, and if authorization is granted, necessary funds to 
effectuate the transaction are transferred. Such a transaction typically involves multiple parties 
including a Card Holder 12, an Acquiring Bank 14, a Merchant 16, a Bank Card Association 18, 
and an Issuing Bank 20. While only one of each party is shown for ease of illustration, it is 
understood that there is may be a plurality of each type of party in the credit card transaction 
system 10. 

[0003] The Card Holder 12 is an entity, such as a person or business, that purchases 

goods or services from the Merchant 16 using a card, such as a credit card or debit card, issued 
by the Issuing Bank 20. The Merchant 16 is an entity, such as a business or person, that sells 
goods or services and is able to accept credit and/or debit cards to complete the sale. The 
Merchant 16 may be a point of sale ("POS") merchant, for example. 
[0004] The Bank Card Association 18 is a card payment service association (such as 

Visa, MasterCard, Discover and American Express) that is made up of member financial 
institutions. The Bank Card Association 18, among other things, sets and enforces rules 
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governing their cards and conducts clearing and settlement processing. The Bank Card 
Association 1 8 neither issues cards nor signs merchants. Instead, it licenses financial 
institutions, such as the Issuing Bank 20, to issue cards, and licenses the Acquiring Bank 14 to 
acquire merchants' sales slips under the Association's brand name. The Bank Card Association 
18 then manages the transfer of transaction data and funds between the Issuing Bank 20 and the 
Acquiring Bank 14. In addition, the Bank Card Association 18 maintains national and 
international networks through which data and funds are moved between the Card Holder 12, the 
Merchant 16, the Acquiring Banks 14 and the Issuing Bank 20. 

[0005] The Acquiring Bank 14 is an entity that owns the legal relationship with the 

Merchant 16. The Acquiring Bank 14 provides services and products to the Merchant 16, and 
buys (acquires) the rights to the sales slips of the Merchant 16. The Acquiring Bank 14 credits 
the value of the sales slip to the Merchant's account at the Acquiring Bank. The Acquiring Bank 

14 effectuates payment to the Merchant 14 upon authorization of a card transaction and charges 
the Merchant 14 a fee for handling each transaction. The Acquiring Bank 14 may have one or 
more Partners 15 that specialize in processing card transactions and/or offers additional services 
and products. The Partner 15 may be a bigger bank, such as J.P. Morgan Chase & Co., New 
York, NY, or a processor of transactions, such as First Data Merchant Services ("FDMS"), 
Melville, NY, for example. The combination of the Acquiring Bank 14 and one or more Partners 

15 is referred to as an "Alliance" 15. 

[0006] The Issuing Bank 20 issues cards to approved Card Holders, such as Card Holder 

12, and sends bills to and collects payment from the Card Holder 12. 

[0007] A Platform 22 serves as the liaison between the Merchant 16 and the Bank Card 

Association 18. The Platform 22 seeks authorization for the credit card transaction and conveys 
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the authorization or rejection to the Merchant 16. The Platform 22 also computes the 
interchange fees associated with each credit card transaction processed by the Merchants 16 in 
accordance with predetermined business rules established by the Bank Card Associations 18. 
The Platform 22 may be FDMS, for example. 

[0008] Thus, suppose the Issuing Bank 20 issues a credit card to the Credit Card Holder 

12 (A). The Credit Card Holder makes a $50.00 purchase at a Merchant 16 (B). Upon inputting 
transaction data, the Merchant 16 requests authorization from the Platform 22 (C). The Platform 
requests authorization from a Bank Card Association 18 (D) and ultimately the Issuing Bank 
20 (E). The request for authorization is transmitted from the Merchant 16 to the Issuing Bank 20 
through the Platform 22 and Bank Card Association 18. The resulting authorization (or 
rejection) (F) is then issued by the Issuing Bank 20 and transmitted back to the Merchant 16 
through the Bank Card Association 18 (G) and the Platform 22 (H). 

[0009] Upon completion of the transaction, the Merchant 16, at some subsequent point in 

time, is paid the transaction price by the Acquiring Bank 14 (I) that has purchased the rights to 
the Merchant's sales slips (J). The Acquiring Bank 14 then receives payment from the Issuing 
Bank 20 (K). The Acquiring Bank 14 and the Issuing Bank 20 typically have their own clearing 
networks to effectuate their payments. For example, the Partner 15 of the Acquiring Bank 14 
may provide a clearing network. 

[0010] Alliances 1 5 typically offer a range of credit and debit related services and 

products to the Merchants 16, such as credit cards, debit cards, electronic check processing, point 
of sale terminals, software, etc. The Alliances 15 may hire sales representatives ("sales reps") to 
offer the services and products to the Merchants 16. The sales reps are typically paid a 
commission for the sale and continued use of an Alliance's services and products. The 
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commission may be based on many factors, such as net sales, net revenues, processing volume, 
the length of the relationship with the merchant, meeting targets, etc. Net sales, net revenues, 
etc., are offset by returns. Sales reps may be compensated based on different compensation plans 
in which commissions may be calculated in different ways. Alliances 15 may also offer many 
different promotional programs to encourage the sale of their services and products. As an added 
incentive to sales reps to sell particular services and products, an Alliance 15 may offer higher 
commissions for the period of time that the promotion is taking place. The computation of 
commissions may therefore be complex. This is particularly true if there are a large number of 
sales reps and multiple, different payment plans, which may be changed over time. 
[0011] Alliances 15 may use custom designed software to calculate commissions for 

their sales reps. Commercially available software may be used, as well. Commissions 
calculation software is typically not flexible enough to handle more than a few payment plans 
that may change over time. Changes in payment plans may require months of rewriting of code 
and troubleshooting for successful implementation. 

Summary of the Invention 
[0012] Prior to March 15, 2003, FDMS employed sales reps on behalf of multiple 

Alliances, to offer their services and products. FDMS paid the employees commissions based on 
the compensation plans of the Alliances represented by the sales rep, and provided the sales reps 
with employment benefits, such as health insurance. The Alliances were therefore relieved of 
the administrative costs of employing and paying the sales reps. FDMS charged the Alliances a 
fee for this service. The sales reps were assigned to offer the services and products of one 
Alliance at a time, and in some cases were assigned to merchants of particular sizes or types, as 
well. 
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[0013] Many (if not all) of the Alliances had multiple compensation plans and the plans 

were be frequently changed. FDMS used customized software to calculate the commissions to 
be paid to the sales reps. Values for a variable used in commissions calculations, basis points to 
be multiplied by net sales, were stored in tables. The business rules defining which basis points 
were applicable to calculate particular commissions for particular sales reps, were written in 
code. Whenever a business rule needed to be changed, the applicable code had to be rewritten. 
Changes could, therefore, take months to implement. 

[0014] To facilitate the incorporation of new rules and the modification of existing rules 

in commissions calculations systems, in embodiments of the present invention, business rules for 
calculating commissions are stored in tables. New business rules may be readily added to 
existing tables or new tables may be readily created. Existing rules may be readily modified. 
[0015] In accordance with one embodiment of the invention, a method of calculating 

commissions is disclosed comprising referencing at least one business rule in a table, wherein the 
business rule associates a variable with at least one condition. The method further comprises 
determining the at least one condition and identifying a value of a variable used to calculate 
commissions based, at least in part, on the at least one condition in the table. The method further 
comprises retrieving a value of at least one transaction and calculating the commissions based, at 
least in part, on the value of the variable and the value of the at least one transaction. The 
commissions may comprise a plurality of commissions components and the method may 
comprise conducting the referencing, determining, identifying, retrieving, and calculating for 
each commissions component, and summing the calculated commissions components. For 
example, a common commissions component paid to a sales rep is residual payments for 
ongoing transactions conducted by a merchant serviced by the sales rep. Residual commissions 
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payments may be a function of basis points and the value of net sales in a time period, such as a 
month. In this example, the applicable basis points are determined based on the age of the 
account (the length of time since the merchant account has been approved, fro example) and the 
approval date. Here, the basis points is a variable and the age and date are conditions. Another 
example of a variable is a fee per sale of equipment. Conditions determining the fee to be paid 
may include whether a minimum number of sales have been made to the merchant and a range 
that the number of sales falls within. The variables and conditions may be associated in a table. 
[0016] In accordance with another embodiment of the invention, a method of calculating 

commissions is disclosed comprising importing data related to a value of at least one transaction 
and calculating commissions based, at least in part, on the value of the at least one transaction 
and a business rule stored in a table. As above, the business rule may associate at least one 
variable with at least one condition, in the table. The variable may be chosen from the group 
consisting of basis points or fees per transaction, for example. The commissions may be 
calculated, at least in part, by multiplying the basis points and the value of the at least one 
transaction. The business rule may also comprise a condition on calculating commissions. The 
commissions may comprise a plurality of commissions components and the condition defines 
whether to calculate a commissions component. The commissions may be calculated by 
calculating each of the plurality of commissions components and summing the calculated 
commissions components. A change in a business rule may be received from the party and the 
business rule may be changed in the table. A business rule may be received from a party and 
stored in a table. The calculated commissions may be stored and a statement may be generated 
summarizing the calculated commissions. 
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[0017] Commissions adjustments may also be calculated to offset the summed 

commissions components. The commissions adjustments may also be calculated based on 
business rules stored in tables. An example of a commissions adjustment is recoup, where 
commissions paid in one time period for a new account that passes a credit approval, must be 
returned or recouped in a subsequent time period, if, for example, the account does not reach a 
minimum level of activity by a certain time after approval. The period of time and level of 
activity are conditions determining whether it is necessary to recoup a commissions payment. 
[0018] In accordance with another embodiment of the invention, a system for calculating 

commissions is disclosed comprising means for importing data related to a value of at lest one 
transaction and means for calculating commissions based, at least in part, on the value of the at 
least one transaction and a business rule stored in a table. 

[0019] In accordance with another embodiment, a system for calculating commissions is 

disclosed comprising a processor and memory coupled to the processor. The memory comprises 
a table comprising at least one business rule. The processor is programmed to calculate 
commissions based, at least in part, on the at least one business rule and a value of at least one 
transaction. The table may comprise a plurality of business rules. The memory may comprise a 
plurality of tables of business rules. 

[0020] In accordance with another embodiment, a system for calculating commissions is 

disclosed comprising memory and a processor coupled to the memory. The processor is 
programmed to reference at least one business rule in a table, wherein the business rule 
associates a variable with at least one condition, determine the at least one condition, identify a 
value of a variable used to calculate commissions based, at least in part, on the at least one 
condition in the table; retrieve a value of at least one transaction; and calculate the commissions 
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based, at least in part, on the value of the variable and the value of the at least one transaction. 
The calculated commissions may comprise a plurality of commissions components. The 
processor may be programmed to calculate each commissions component, as described above. 
The processor is then further programmed to sum the calculated commissions components. 

Brief Description of the Drawings 
[0021] Fig. 1 is a schematic diagram of an example of a credit and debit card transaction 

system in the United States; 

[0022] Fig. 2 is a block diagram of an example of a Commission Calculating System 

("CCS") that may implement embodiments of the present invention; 
[0023] Fig. 3 is another schematic diagram of the CCS of Fig. 2, showing the Data 

Source and the Commissions Calculator in more detail, in accordance with an embodiment of the 
present invention; 

[0024] Fig. 4 is an example of a method of calculating commissions in accordance with 

an embodiment of the invention; 

[0025] Fig. 5 is an example of a residual basis points table, referred to as a 

RESK)_BASISPNTS table, for selecting the value of the basis points to be used in calculating 
residual payments in one implementation; 

[0026] Fig. 6 is an example of a RESID AGEMONTH Table used to determine whether 

residuals should be paid, in one implementation; and 

[0027] Fig. 7 is an example of a method of incorporating business rules in tables in 

accordance with an embodiment of the invention. 

Detailed Description of the Preferred Embodiments 
[0028] Methods and systems for automatically calculating sales commissions based on 

predetermined business rules are disclosed. In one embodiment, the business rules are stored in 
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tables, facilitating the incorporation of new rules and changes in existing rules. Business rules 
may comprise associations between variables upon which commissions or components of 
commissions are calculated and conditions that determine the applicability of particular variables 
in particular circumstances. For example, a commissions calculation may be a function of the 
product of sales generated by an account and basis points. In this function, the value of the basis 
points is a variable. The particular basis points applied may depend, at last in part, on the age of 
an account generating the sales and a date the account was approved. The age and date are 
conditions. Values for the variables and the conditions may populate fields in the table. In one 
example of a table, fields in a row are associated and define one or more business rules. A 
business rule may only comprise conditions. For example, whether commissions paid in one 
period for enrolling an account needs to be debited against commissions earned in a subsequent 
period (recoup), may depend on whether the account has been activated by conducting a 
sufficient level of transactions within a predetermined period of time of being approved (by 
passing a credit check). In this example, the time period and the level of transactions are 
conditions of business rules that may be stored in tables. Functions or equations used to 
calculate commissions using the values of the variables may be written in software. 
[0029] The commissions paid may be a sum of a variety of types of commissions, 

referred to as "commissions components," which may be offset by commissions adjustments. 
The values of the commissions components are functions of a variety of inputs related to net 
sales, net revenues, etc., attributable to the sales rep. As mentioned above, net sales and 
revenues are offset by returns. In the implementations described herein, reference to sales, 
revenues, or other values upon which commissions are calculated, means net sales, revenues, 
etc., but that is not required to practice the invention. 



30747320.DOC 



9 



[0030] In one example, sales reps represent one party, such as one Alliance 15. Sales 

reps may represent multiple parties as well. The Alliance 15 establishes one or more 
compensation plans defining business rules for use in calculating commissions. A sales rep may 
be compensated in accordance with one or more compensation plans. The sales reps have 
portfolios of merchants 16 that they have enrolled into an Alliance's program. Sales attributable 
to a sales rep include direct sales of services or products to merchants 16 and sales generated by 
merchants in a sales rep's portfolio, by conducting card transactions. Such transactions include 
credit card and debit card sales transactions with customers. Revenues attributed to a sales rep 
are the fees paid by merchants 16 in a sales rep's portfolio, typically per transaction, sale, lease, 
installation, etc. The applicable commissions components, the functions for calculating the 
commissions components, and the business rules determining the variables of the functions are 
defined by the Alliance 15 represented by the sales rep and the applicable compensation plan. 
An Alliance may determine that the commissions paid are based on only one component, as well. 
[0031] In general, sales reps are paid commissions for establishing new merchant 

accounts by enrolling new merchants into a program sponsored by an Alliance and for the 
transactions conducted by the accounts in their portfolio. Sales generated in a time period for 
each merchant account is typically a significant factor in calculating commissions for a sales rep 
representing that account. Revenues earned by an Alliance based on transaction fees may be 
considered along with or instead of sales. 

[0032] For example, one commissions component, referred to as "residuals" or "residual 

payments," is based on a percentage of a value of transactions generated by each account 
represented by the sales rep, in a time period. The value of the transactions may be the net sales, 
for example, which is multiplied by predetermined basis points to yield the residual payment 
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commissions component. Residual payments in a time period may be capped. A minimum 
value of sales may have to be met in the time period before any residuals are paid. The 
predetermined basis points applied to calculate the residual payment may be based on the length 
of time the merchant has been enrolled, approved (passed credit check) or activated (met a 
predetermined level of activity) in a particular program, referred to as the "age" of the account, 
and may decrease as the age increases, for example. There may be limits on the length of time 
that residuals are paid for an account, such as for five years, for example. There may also be 
minimum levels that must be met in a time period before a residual payment is made for that 
time period. The valued for the basis points and the associated conditions are determined by and 
may differ among the Alliances 15 and among the Alliance's compensation plans. The variables, 
these conditions, and identifications of a sales rep servicing the account, the Alliance represented 
by the sales rep, and the compensation plan applicable to the sales rep, may be associated in one 
or more tables for calculation of this commissions component. Since the basis points are also 
dependent on the sales rep and Alliance compensation plan, they may also be conditions in the 
business rules for calculating this and other commissions components discussed below, 
depending on how the tables are organized. Other business rules may be used instead of or along 
with these rules. 

[0033] Another commissions component in this example, referred to as "revenue 

performance," is based on revenues earned from the fees paid by merchant accounts in a sales 
rep's portfolio, to the Alliance 15. The revenues attributable to a sales rep for each merchant 
account may be a function of the product of the revenues generated by that account and a 
particular value of basis points. In one example, the particular basis points, which is a variable, 
depends on a level of revenues achieved, which is a condition, as defined by business rules. In 
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particular, an expected level of revenues is established by the Alliance for each merchant account 
in the sales rep's portfolio. The business rules may associate basis points values with ranges 
defining the relation between the actual revenues and the expected level. For example, if the 
actual revenues is from 65% to 75% of the expected revenues, a first basis points is selected from 
the table. If the actual revenues is greater than 75% but less than or equal to 100%, a second 
basis points greater than the first basis points is selected from the table. If the actual revenues is 
greater than 100% of the expected revenues, a third, higher basis points is selected from the 
table. Additional ranges and basis points may be provided, as well. These variables and 
conditions may be associated with the applicable sales rep, Alliance and compensation plans in a 
table, as discussed above. The Alliance and compensations may vary the ranges and associated 
basis points in their business rules. Other business rules may be used, as well. 
[0034] Another commissions component may be earned for the approval of new 

merchants 16 in an Alliance's programs. As mentioned above, the approval process typically 
involves a credit check of the merchant 16. A fixed amount may be paid for each account 
approved in a time period. The fixed amount paid, which is the variable, may vary based on the 
actual number of new accounts approved, which is a condition, in the business rules. Different 
fixed amounts may be paid for each of the first 10 accounts signed in a time period, and each of 
the next 10 accounts signed in that time period, for example. Such ranges are also conditions. 
Another condition may be that a minimum number of new accounts must be met before any 
commissions are paid. In one example, a commission component, referred to as a "Masters Club 
Bonus," is earned for enrolling more than a particular number of new accounts in a time period, 
such as one month. The variables and conditions are determined by the business rules of the 
compensation plan of the respective Alliance 15 applicable to a particular sales rep. The fixed 
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amounts and ranges may be correlated with the sales rep servicing the account, the Alliance 
represented by the sales rep and the applicable compensation plan, in one or more tables. Other 
business rules may be used as well. 

[0035] Commissions are also paid for sales or revenues generated from special 

promotions. Special promotions may be established by Alliances 15, typically for limited 
periods of time, to provide added incentives for the sales reps to sell particular services or 
products. Such a bonus may be instituted to invigorate sales of lagging offerings, for example. 
In this implementation, a commissions component based on the sales of particular products and 
services is referred to as a Product Emphasis Bonus ("PEB"). The functions for calculating this 
commissions component and the business rules defining the variables and conditions may be 
similar to the calculation of the residual commissions component or the revenue performance 
commissions component, discussed above, depending on whether the commissions are based on 
sales or revenues, respectively. Similar associations may be provided in one or more tables. The 
commissions may be calculated based on other business rules, as well. 

[0036] One or more commissions components may relate to equipment and products for 

an Alliance 15, such as credit and debit card validation terminals, printers, software, and Internet 
services. For example, a product sale commissions component and a product lease commissions 
component may be calculated for the sale and/or lease of such products, respectively. The 
commissions may be a function of a product of the net sales, net revenues (from fees associated 
with the transaction) and/or net number of units sold, for example, and applicable basis points. 
Conditions may include a minimum level of sales or value of sales or revenue, and/or unit sales 
or revenue growth targets that need to be met before any commissions are paid. If this 
commissions component for a particular Alliance compensation plan for a particular sales rep is 



30747320.DOC 



13 



based on sales or revenues, the functions and business rules may be similar to the residual or 
revenue components, respectively, which are discussed above. If this commissions component 
for an Alliance compensation plan for a particular sales rep is based on units sold, the functions 
and business rules may be similar to the Master Club Bonus component. As above, the business 
rules are stored in one or more tables. The commissions for any or all of the sales reps may be 
calculated based on other business rules, as well. 

[0037] Another commissions component may relate to the installation of equipment or 

software, for example. Installation may include setting up a POS terminal, for example. If this 
commissions component for an Alliance compensation plan is based on units sold, the business 
rules may be similar to the Master Club Bonus component. If this commissions component for 
an Alliance compensation plan is based on sales or revenues generated by the installed 
equipment, the business rules may be similar to the residual or revenue components, 
respectively. In either case, the business rules may be stored in one or more tables. The 
commissions may be calculated based on other business rules, as well. 
[0038] The commissions components above are examples. Alliances 15 may have 

compensation plans based on any or all these commissions components, which may be calculated 
based on similar or different business rules. Other commissions components may be used 
instead or along with the commissions components discussed above. The same commissions 
components may be calculated differently for different sales reps, dependent upon the Alliance 
they represent and the applicable compensation plan. 

[0039] As mentioned above, the applicable commissions component or the sum of 

applicable commissions components may be offset by one or more commissions adjustments to 
determine the commissions paid. One common commissions adjustment is referred to as 
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"recoup." Recoup may be required when an Alliance authorizes the payment of commissions at 
the time of account approval, if the merchant 16 does not start processing transactions or does 
not meet a minimum level or value of transactions, in a predetermined time period, for example. 
Use or sufficient use is referred to as "activation." In that case, the commissions payment, which 
may have been earned in the Master Club Bonus, for example, is returned in a subsequent time 
period. Typically, the amount of the advance commission is subtracted from the sum of the 
earned commissions in the subsequent time period. 

[0040] Business rules related to calculating recoup may define a time period after 

payment to the sales rep that the merchant account must activate or commissions are recouped, 
as determined by the Alliance compensation plan. The time period may be 60 or 90 days, for 
example. In this case, the time period and minimal value of activity are conditions. After the 
Master Club Bonus or other such commissions component is calculated based on approved 
accounts, the accounts may be stored in a table including fields to indicate the account approval 
date, whether the account has been activated, the activation date, if any, the sales rep servicing 
the account, the Alliance represented by the sales rep and the applicable compensation plan. 
When sufficient activity is met, a flag is set in the appropriate field, and the date is entered in the 
date field, for example. If the field for the date does not indicate that activation has taken place 
by the number of days after approval defined by the business rules, then the commissions paid 
for that account is recouped in a current time period. The commissions paid is typically 
recouped by debiting the commissions earned in the current time period. 
[0041] Another type of adjustment that may need to be made is referred to as 

miscellaneous adjustments, which compensate for commissions paid outside of a regular pay 
cycle. Operational discrepancies or adjustments caused by the late receipt of data required to 
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compute a commissions component in a proper time period, for example, may require such 
adjustments. Other adjustments may be provided along with or instead of either or both of these 
adjustments. 

[0042] Fig. 2 is a block diagram of an example of a Commissions Calculating System 

("CCS") 100 that may implement embodiments of the present invention. The CCS 100 may 
comprise a Data Source 1 10 comprising a processor 112 and memory 114. The Data Source 110 
accumulates data needed to calculate commissions and provides the data to a Commissions 
Calculator 120, which may also comprise a processor 122 and a memory 124. The Commissions 
Calculator 120 calculates commissions based on the data provided by the Data Source 110 and 
business rules stored in the memory 122. The Commissions Calculator 120 may provide the 
calculated commissions to a Commissions Payment Manager 130, which causes payment to sales 
representatives of the calculated commissions. The Commissions Payment Manager 130 may be 
part of the payroll department of the CSS 100. 

[0043] As discussed above, a third party, such as FDMS, may hire sales reps to market 

the products and services of one or more Alliances 15 and pay commissions to the sales reps 
acting on behalf of the Alliances. A Billing Manager 140 may be provided to bill the Alliances 
15 for the commissions paid to respective sales reps. The Billing Manager 140 may also 
compute a service charge to be included in the bill. The Billing Manager 140 may comprise a 
processor 142 and a memory 144. It is noted that the third party may also be the transaction 
processor or Platform 22 for the Alliances 15, as discussed above with respect to Fig. 1, but that 
is not required. 

[0044] While one Data Source 1 10 is shown comprising one processor 1 12 and memory 

1 14, a plurality of Data Sources 110 may be provided and/or a plurality of processors 112 and 
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memory 1 14 may be provided in each Data Source 1 10. One or more Data Sources 110 may be 
at different locations and/or may be dedicated to different classes of sales reps servicing different 
classes of merchants, as described further, below. Multiple processors and memory may be 
provided in the other components of the CCS 100, as well. 

[0045] When a merchant agrees to purchase a new service or product promoted by a sales 

rep, the terms of the transaction are typically memorialized in and defined by a contract, referred 
to as a Merchant's Agreement. Some of the information required by the Commissions 
Calculator 120 is derived from the Merchant Agreements. The information may be entered into 
the Data Source 1 10 to be stored in the memory 1 12 by the CCS 100 or by the respective sales 
rep, via personal computers 160a, 160b, 160c through 160n, for example. The personal 
computers 160a through 160n may be connected to the Data Source 1 10 via an intranet or other 
such network, for example. The Merchant Agreement may also be scanned into the Data Source 
1 10 (or another such data source), to be stored in memory 1 12 as an image. 
[0046] The Data Source 110 may be a mainframe computer, such as an IBM Mainframe. 

The Commissions Calculator 120 may be a server, such as a server from Dell Corporation, 
Redrock, Texas. The memory 122 may comprise a database, such as an Oracle database server, 
available from Oracle Corporation, Redwood Shares, California. 

[0047] The memory 1 14 of the Data Source 110 may comprise one or more databases to 

store information needed to conduct the commissions calculations. Some of the required 
information is obtained from the Merchant's Agreements, as mentioned above. Information 
related to transactions conducted by the merchants 16 may be provided by the Platform 22 of 
Fig.l to the Data Source 110. The transaction information may be itemized for each merchant 
16. For example, the total dollar value of the transactions conducted by a merchant 16 in a time 
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period and the total dollar value of revenues generated by the merchant in the time period may be 
provided. The CCS 100 may sell and lease equipment on behalf of respective Alliances 15. 
Data concerning sales, lease and installation of equipment is therefore readily available to the 
Data Source 110. 

[0048] Fig. 3 is another schematic diagram of the CCS 100 of Fig. 2, showing the Data 

Source 110 and the Commissions Calculator 120 in more detail. In this example, the memory 
1 14 of the Data Source 1 10 is shown comprising a plurality of databases 202 through 216, in 
which data required for the commissions calculation is stored. 

[0049] A Sales Rep database 202 may be provided to store identifying information about 

the sales reps, such as their name, mailing address, hire date, termination date (if any), the 
Alliance or Alliances 15 they currently represent and have represented in the past, associated 
start and end dates for those representations, the applicable compensation plan or plans of each 
Alliance, the applicable time periods for the applicable plans, the merchant accounts serviced, 
etc. 

[0050] A Merchant Master File database 204 stores accumulated transactional 

information related to each merchant account, such as total sales and revenues in a time period, 
to be used to calculate the commissions in the time period, as mentioned above. Other 
information stored in this database may include an identification of the sales rep servicing the 
account, the merchant approval date, the merchant activation date, and the accumulated number 
of enrolled, approved and/or activated accounts in the sales reps portfolio in a current time 
period. Residual, revenue, and Master Club bonus commissions components, for example, may 
be calculated based, at least in part, on the information in this database. Data concerning 
individual transactions related to each merchant account may be provided from the Platform 22 
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to be accumulated in the Merchant Master File database 202 or the data may be accumulated by 
the Platform or the processor 112 prior to storage in the database. 

[0051] A Financial History database 206 stores accumulated sales/revenue information 

for each merchant from prior time periods. This information may be provided by the Merchant 
Master File database 204. Past information may be needed to calculate residuals and recoup, for 
example. 

[0052] A PEBs database 208 is provided to store accumulated information related to the 

Product Emphasis Bonus commissions component. The information may include total sales of 
the particular services or products subject to the PEBs bonus per merchant account. The 
responsible sales rep may be identified here, as well. If the sales reps and their merchant 
accounts are correlated in the Sales Rep database 202 ? then it is not necessary to include the 
information about the sales rep here and in other databases dedicated to commissions 
components. 

[0053] An Equipment database 210 contains information about equipment sales, such as 

credit card validation terminals, printers, software, Internet services, etc., and the merchant 
making the purchase, which is used to calculate the product sale commissions component. A 
Lease database 212 contains information about leased equipment and the merchant the 
equipment is being leased to, which is used to calculate the product lease commissions 
component. Installation information may be stored in the Equipment database 210, the Lease 
database 212 or in another database (not shown), for example. The Equipment database 210 and 
the Lease database 212 may be readily combined. 
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[0054] The Scanning database 214 contains images of the scanned Merchant 

Agreements, discussed above. Storing the Agreements enables the Agreements to be checked, if 
necessary. 

[0055] A Global Fee database 218 stores the accumulated fees charged each merchant 16 

by the Alliance 15 and Card Associations 18 to conduct each type of transaction, throughout the 
world. The accumulated fees include the discount rate charged by the sales rep servicing the 
account for the Alliances 15, minus the interchange fee charged by the Card Associations 18, 
plus assessments charged by clearing networks 13. Revenues in the calculation of commissions 
components may be based on fees, such as the discount rate, charged to the merchant account, 
for conducting transactions. Many different types of fees may be charged per transaction for 
different contracted services requested by the merchant. Contracted services include the type 
statement to be received and account credit, for example. 

[0056] The databases 202 through 216 are merely examples of ways to organize and 

store information. The information may be organized and stored in other ways, as well. 
[0057] The data from the databases 202 through 218 is provided to the Commissions 

Calculator 120 in the form of one or more ASCII files via an SQL feed, for example. An ASCII 
file may be provided from each database, for example. The Commissions Calculator 120 
comprises a Data Tables database 230, a Business Rules Tables database 232, and a Calculator 
234. The Calculator includes a memory 236. The Commissions Calculator 120 loads the data 
received from the Data Source 110 into tables in the Data Tables database 230. Teh variables 
and conditions in the business rules are stored in tables in the Business Rules Tables database 
232. 
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[0058] In the tables, applicable business rules are preferably associated with the sales rep, 

the represented Alliance, the applicable compensation plan of each Alliance, the merchant 
account, etc., as appropriate. Information in the Financial History database 206 is provided to 
the Commissions Calculator 120 upon the request of the Calculator 120, when needed to perform 
certain calculations. 

[0059] The Calculator 234, which may be part of the processor 122 of Fig. 2 or may be 

another processor or processors, calculates the commissions for each sales rep, based on the data 
in the Data Tables database 230 and the business rules in the Business Rules database 232. The 
commissions components described above are calculated and stored in the memory 236. 
[0060] The stored values for the calculated commissions components are summed to 

yield a gross calculated commissions for each sales rep, which are also stored in the memory 
236. Miscellaneous adjustments are calculated, to determine payments made to some sales reps 
outside of the regular pay cycles. Operational discrepancies or adjustments due to late receipt of 
data, for example, may cause such adjustments. The miscellaneous adjustments for each sales 
rep, if any, are stored in the memory 236, as well. Recoup is then calculated for each sales rep, 
to determine how much, if any, money needs to be returned by a sales rep. The recoup value, if 
any, is stored in the memory 236, as well. The adjustments may be calculated in any order. 
[0061] The gross calculated commissions for each sales rep is offset by the miscellaneous 

adjustments and the recoup, if applicable, to yield a net calculated commissions for each sales 
rep. This is done by subtracting the miscellaneous adjustments and the recoup from the gross 
calculated commissions, for each sales rep. The sales rep is paid the net calculated commissions. 
[0062] The Commissions Calculator 120 may comprise a plurality of modules to 

accommodate different business rules. Different modules may be dedicated to different 
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classifications of sales reps or merchants. For example, business rules may vary based on the 
size of merchant account or location of the merchant, for example. Providing separate modules 
dedicated to particular classes may facilitate processing, because only the applicable business 
rules need to be stored in that module. Sales reps that work with merchants above a particular 
revenue range, such as 2.5 million dollars, may be handled by one module. Sales reps working 
with smaller sized merchants may be handled by another. Sales reps working with overseas 
(non-US) merchants may be handled by an overseas module. Sales reps may work with different 
merchant accounts that may be handled by different modules. A module may be provided to 
handle all sales reps, as well. 

[0063] Accumulated data for each month may be provided from the Data Source 1 1 0 to 

the Commissions Calculator 120 on the 1st day of the following month. Commissions may be 
calculated and paid by the end of every month. 

[0064] The Commissions Calculator 120 also comprises a Commissions Database 240, a 

Commissions History database 242, a Commissions Inquiry system 244 and a Statement 
Generator 246. The net calculated commissions for each sales rep, as well as the commissions 
components and adjustments for a period of time, are stored in the Commissions Database 240. 
The time period may be 13 months, for example. All the paid commissions and the underlying 
components and adjustments for the life of the CCS 100 are stored in the Commissions History 
database 242. The Commissions Inquiry System 244 is provided to handle inquiries by sales rep. 
The Commissions Inquiry System 244 has access to the Commissions History database 242 for 
information necessary to respond to inquiries concerning paid commissions. 
[0065] The Statement Generator 246 generates summary statements itemizing the 

commissions components, gross calculated commissions, miscellaneous adjustments, recoup and 
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net calculated commissions, based on information provided by the Calculator 236. The 
statements are mailed to each sales rep. The Statement Generator 246 also prints a statement for 
each sales rep for the Commissions Payment Manager 130. The Payment Manager 130 
effectuates payment to the sales rep based on the statement. The statement provided to the 
Payment Manager 130 may contain only the net calculated commissions or it may be an itemized 
statement of the earned commissions components, the gross calculated commissions, the 
miscellaneous adjustment and the recoup for each sales rep. The statement or other such 
document may also be provided to the Billing Manager 140, which bills each participating 
Alliance 15 for the payments made to the sales reps representing that Alliance. The Alliance 15 
typically expects an itemized statement. 

[0066] Fig. 4 is a summary 300 of the example of a method of calculating commissions 

in accordance with an embodiment of the invention, described above. Data necessary for the 
calculations is imported, in Step 302. Commissions components are calculated for each sales rep 
based on business rules stored in tables, in Step 304. The commissions components are summed 
to yield a gross calculated commissions for each sales rep, in Step 306. Miscellaneous 
adjustments are calculated for each sales rep, in Step 308. Recoup is calculated for each sales 
rep, in Step 310. The summed commissions components, referred to above as the gross 
calculated commissions, is offset by the calculated adjustments and recoup for each sales rep, if 
any, to yield a net calculated commissions for each sales rep, in Step 312. The commissions 
components, miscellaneous adjustments and recoup for each sales rep are stored, in Step 314. In 
the example described above, the information is stored to the Commissions Database 240 and the 
Commissions History database 242. Statements summarizing the commissions components, 
miscellaneous adjustments and recoup for each sales rep are generated, in Step 316. The sales 
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rep, the payroll department of the CCS 100 and the billing department of the CCS receive 
statements in the same or different formats. 

[0067] Examples of tables of business rules for calculating residual payments are 

discussed in more detail, below. Tables and calculations for other commissions components may 
be similar. 

[0068] As discussed above, commissions based on transactions generated by existing 

merchants in a sales rep's portfolio are referred to as "residual payments" or "residuals." 
Residual payments are typically a function of a percentage of a value of the transactions in a time 
period. The "value" of the transactions may be based on net sales, for example. Net revenues 
may be used instead. The percentage or basis points applied to the value may be determined by 
business rules based on conditions such as the age of the account in months or years, which may 
be calculated by comparing the credit approval date or activation date of the merchant's account, 
as defined by the business rules, with an end date of a current time period. The basis points may 
decrease (or increase) as the account ages. Business rule conditions may also define minimum 
values that must be met for any residual to be paid for a particular account. The business rules 
may also associate particular basis points with particular achieved level of sales, for example. 
Business rules may also limit the period of time that residuals may be paid, such as for up to 5 
years. Business rules may also limit total residual payments that a sales rep may receive per time 
period, such as per month, per year, or over the total period that residuals may be received. 
These business rules are typically established by the Alliance represented by the sales rep, and 
may vary among different Alliances and the different compensation plans of an Alliance. 
[0069] In one implementation, basic information identifying each sales rep, each Alliance 

15, each compensation plan of each Alliance, and each merchant account are stored in respective 
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sales person tables, Alliance tables and sales plan tables. A salespersons table is provided for 
each sales rep. Each salesperson table includes an identification number of a respective sales rep 
employed by the CCS 100, along with the full name, address, start date with the CCS, and end 
date (if there is one) of the sales rep. Each Alliance table correlates an Alliance name with a 
code identifying the Alliance (referred to as a "Marker"), an address of the Alliance, a start date 
of the Alliance with the CCS 100 and an end date (if there is one) of the Alliance with the CCS. 
A sales plan table is also provided for each sales rep to correlate the sales rep with the Alliance 
or Alliances the sales rep has or is representing and the plan code or codes of the applicable 
compensation plans of the Alliance applicable to the sales rep. The start date and end date (if 
there is one) for each applicable plan are included, as well. As mentioned above, a sales rep may 
represent multiple Alliances and may be compensated under different plans, depending on the 
merchant and the relevant time period. Each merchant account table includes the merchant's 
identification number, address, approval date, activation date, and associated sales rep. 
[0070] Fig. 5 is an example of a portion of a RESID_BASISPNTS Table used to 

determine the value of the basis points to be used in calculating residual payments in this 
implementation, for certain of the business rules for the Alliance (marker) 615, compensation 
plan (plan code) Al. Here, the business rules dictate that applicable basis points (variable) are 
determined, at least in part, based on the age of the account and the start date of the account 
(conditions). The column headings of the RESIDJ3ASISPNTS table of Fig. 5 are summarized 
in Table I, below. The name of each field (Field Name) and a brief description of the contents of 
the field (Record Contents) are indicated. Additional business rules related to caps on residual 
payments based on the start date of the account and the age of the account are provided, as well. 
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Exemplary values are shown. Business rules related to residual payments for other 
compensation plans of this and other Alliances may be provided in this or other tables. 



Table I 



rieia iName 


Kecora moments 






iviarKer 


UJ oi Alliance 






Jriancooe 


— — — — : 

Plan Code of Alliance Compensation Plan 
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Basispoints 


Basis Points Value 






PayMonths 


Number of Months Residuals to be Paid 






Capamount 


Cap (Maximum) Amount of Residual Payments 






Startdate 


Start Date of Account Initiation Period 






Enddate 


End date of Account Initiation Period 



[0071] In Table I, a Marker uniquely identifies each Alliance by numbers, letters or both. 

A Plancode identifies a compensation plan of the Alliance, also by a number, letters or both. 
Bpts_year is the age in years of the merchant account. In this example, each Bpts_year is 12 
months long. Bpts_year 1 is the first 12 months of the life of the account. Bpts_year 2 is the 
second 12 months of the life of the account (months 13-24), etc. Basis points is the value of the 
percentage used to calculate a residual payment for an account of a particular age. Twelve (12) 
basis points, for example, is 12%. Typically, the value of the basis points decreases as the age 
increases, but other arrangements are possible. 

[0072] PayJMonths is the number of months for which residuals will be paid. For 

example, the Alliance 615 limits residual payments to 60 months (five years) in plan Al. 
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[0073] Capamount is the maximum amount of residual payments in dollars that may be 

paid per year, if any. This amount may also decrease (or increase) each year. 
[0074] In this example, the business rules dictate that the applicable basis points differ 

based on when a merchant account is approved or activated, dependent on the business rules. 
Startdate and Enddate defines conditional time periods. In this example, for Plan Code Al of 
Alliance 615, the business rules are different for accounts approved or activated from May 1, 
1999 through December 31, 2000, and January 1, 2001 through June 30, 2002. 
[0075] Summarizing the business rules in the Table I for Marker 615, Plancode Al, for a 

merchant account approved or activated in a program between May 1, 1999 and December 31, 
2000, the basis points applicable to the first basis points year (Bpts_year 1) is 15. There is a cap 
of $1,000 in residual payments on that account, and residuals are paid for 60 months. The basis 
points for that same merchant account in the Bpts_years 2, 3, 4, and 5 is 7, 5, 4 and 3, 
respectively. In Bpts_years 4 and 5, the Capamount decreases to $750 and $500, respectively. 
Since the PayJVlonths for an account approved or activated between January 1, 2001 and 
June 30, 2002 is 60 months, there are 5 Bpts_years. All other columns are the same. 
[0076] For the same Alliance and compensation plan, in accordance with other business 

rules, for a merchant account approved or activated between January 1, 2001 and June 30, 2002, 

the basis points applicable to Bpts year 1, 2 and 3 is 10. There is no cap and residuals are paid 

for 36 months. Since the Pay_Months for an account approved or activated between January 1, 
2001 and June 30, 2002 is only 36 months, there are only 3 Bpts_years. 
[0077] An Alliance may require that certain levels of sales or revenues be achieved 

before paying residuals. Business rules may correlate the particular levels that must be achieved 
with particular time periods. Fig. 6 is an example of a RESEDAGEMONTH Table used to 
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determine whether residuals should be paid in accordance with additional business rules in any 
particular month in which residuals may be paid. The name of each field and a brief description 
of the contents of the field are summarized in Table II, below. 
Table II 



meld JMame 


Record Contents 





— 


Marker 


ID of Alliance 






— 

Plancode 


rian uoae 01 Alliance compensation rian 






rromage 


oianing lviontn ior i^uauiication i ear 






TViq ere* 
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Chkjable 


"A" if CMHSTAC Table is to be checked, "Q" if 
RESQUAL Table is to be checked, and "0" if no 
table is to be checked for qualification. 






Bpts_year 


Basis Points Year 






Qlyrbase 


Qualification Year Base 






Startdate 


Start Date 






Enddate 


End date 



[0078] The Marker and Plancode fields were described above. A ChkJTable field 

indicates whether other tables, referred to as CMHSTAC and RESQUAL (residual qualification) 
need to be checked for qualifications. In this example, "A" indicates that the CMHSTAC table 
needs to be checked, "Q" indicates that the RESQUAL table needs to be checked and "O" 
indicates that no table need be checked. If no table needs to be checked, then residuals are paid 
based on the basis points of the Bpts_year, and the total sales/revenues for that time period, as 
determined in Table I. 
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[0079] The CMHSTAC table (not shown) associates achievement levels of net sales with 

time periods in which those levels must be met, for the sales rep to receive residuals in that time 
period. For example, a certain level of net sales may need to be met in the month after approval 
of an account, for residuals to be paid. RESQUAL is a residual qualification table (not shown) 
used to indicate whether an achievement level required in CMHSTAC in a time period has been 
met and to store the actual sales or revenues in that time period. 

[0080] In this example, a business rule requires that in months 1-4, an achievement level 

need not be met for residuals to be paid. Another table need not, therefore be referred to to 
determine if residuals should be paid and a flag in the CHKJTable field is set to "O," in the row 
including months 1-4. Another business rule requires that in month 5, an achievement level must 
be met for residuals to be paid. The CMHSTAC table therefore needs to be checked to 
determine whether the generated sales or revenues qualify for residual payments. A flag in the 
CHK_Table field is therefore set to "A." Another business rule requires that once an 
achievement level is met in the month 5 then achievement levels do not need to be checked again 
in months 6-13. The flag in the CHK_Table is therefore set to Q for months 6-13, indicating that 
the RESQUAL table needs to be checked to determine whether the required achievement level 
was met in month 5. If yes, then residuals are paid in each of months 6-13. If not, then no 
residuals are paid in those months. Another business rule requires that an achievement level be 
met in month 14 for a residual payment to be made. Therefore, in month 14, the flag in the 
CHKTable field is set to "A." In months 15-25, 26-37, 38-49, and 50-61, the flag in the 
CHKJTable is set to "Q The RESQUAL table is therefore checked to confirm that the 
achievement level was met in the month 14. Months 15-25, 26-37, 38-49, and 50-61 are in 
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Bpts_years 2, 3, 4 and 5, respectively. If it was not met in month 14, then residuals are not paid 
from month 15 through month 61. 

[0081] Qlyr_base is a qualification year base, which indicates whether the date from 

which Fromage, Toage, Bpts_year and Startdate, Enddate in the RESIDBPNTS Table of Fig. 5 
is calculated, referred to as the critical date, is the account approval date or the account activation 
date, in accordance with another business rule of the Alliance compensation plan. "A" indicates 
activation date, "C" indicates approval date. In this example, the flag in the Qlyr_base is set to 
C, indicating that the critical date is the approval date. 

[0082] Startdate and Enddate in the RESID_AGEMONTH of Fig. 6 are time ranges 

within which the critical date may fall. Business rules may vary based on this range, as in the 
RESIDBASISPTS, table of Fig. 5. In this example, however, different sets of business rules are 
not provided for rules in the RESED AGEMONTH table for the Plan Code Al of the Marker 
(Alliance) 615. The Startdate is therefore the start date for the CCS 100 and the Enddate is left 
blank. Business rules in this table for other Alliance plan codes could vary based on the critical 
date and then these columns would be filled. 

[0083] If there are any changes to the business rules governing the determination of basis 

points or Bpts_years applicable in a particular Alliance compensation plan, then the values in the 
appropriate RESIDBASISPTS Table may be readily changed. If there are any changes to the 
business rules governing the qualification levels, such as the range of months associated with 
indications of checking the CMHSTAC or RESQUAL tables, the changes may be readily made 
in the RESID_AGEMONTH Table. The qualification tables (CMHSTAC and RESQUAL) may 
be readily changed as well. New residual payment business rules may be readily provided in 
these, other or new tables, as well. New fields can be added or fields removed, as necessary. 
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[0084] An example of how the tables are used to calculate residuals will now be 

described. To conduct the residual payment component calculation, the RESID_BASISPNTS 
table, the RESIDAGEMONTH Table, along with other tables, such as the CMHSTAC, 
RESQUAL, salespersons, Alliance, sales plan and merchant tables are retrieved from the 
Business Rules Tables database 232 by the Calculator 234 and stored in the memory 236. The 
memory 236 may be a database, as well. The tables are validated to check the integrity of the 
data in the fields. Errors in fields require correction. 

[0085] A residual input table (not shown) may be created and populated with 

accumulated data related to all the merchant accounts in the Data Tables database 230. The data 
is provided by the Data Source 110. The residual input table correlates a marker and a plan code, 
an identification of the merchant, an account approval date, an account activation date, an 
identification of the sales rep servicing that account, the Alliance the sales rep represents, the 
compensation plan applicable to the sales rep and the total sales and/or revenues in the period 
generated by that account. A chain field may be provided to identify whether a merchant is part 
of a chain and to identify the chain. Commissions components may be based on the accumulated 
sales and/or revenues for an entire chain, as determined by the business rules. A field is 
provided to indicate whether the data in other fields has been validated, as discussed below. The 
input table may be populated in the Data Tables database 230 and/or in the memory 236 of the 
Calculator 234, for example. 

[0086] Prior to calculating the residuals for a sales rep, data in the residual input table is 

validated. The identity of the sales rep is checked based on the salesperson table. The marker 
identifying the Alliance is checked in the Alliance table. The plan code is checked in the sales 
plan table. The length of the merchant identification code for each merchant and chain 
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identification code are checked to ensure that they have the proper lengths. If any validation 
fails, then a flag is set in the validation field and that data is not used. 

[0087] The age of each merchant account in months is calculated, based on the activation 

date or the account approval date and the current date, for example, as determined by the 
Alliance 15 and applicable compensation plan. The age may be determined by the Calculator 
234. The procedure may be in the code of the software controlling operation of the Calculator 
234. The age of each merchant account is stored in a table or tables in the Data Tables 230 and 
or the memory 236. 

[0088] Once the age of the account is determined, applicable business rule or rules are 

referenced in an appropriate table in the Business Rules Tables database 232. In the example, 
the age is compared to the Fromage and Toage columns of the RESIDAGEMONTH Table of 
Fig. 6 by the Calculator 234, to determine which row defines the other aspects of the applicable 
business rules. If the account is three months old, for example, it falls within the first row of the 
RESIDAGEMONTH Table of Fig. 6. The Bpts_year is 1 and the CHKJTable entry is O. It is 
not, therefore, necessary to check the achievement tables (CMHSTAC or RESQUAL). The 
RESID_BASISPNTS Table of Fig. 5 is then checked by the Calculator 234 to determine the 
applicable basis points for a Bpts_year of 1 . If the merchant account was approved (or activated, 
depending on another business rule) between May 1, 1999 and December 31, 2000, for example, 
the applicable basis points is 15. If the merchant account was approved (or activated) between 
January 2, 2001 and June 30, 2002, for example, then the applicable basis points is 10. The 
applicable basis points in percentages is multiplied by the sales for that merchant account 
retrieved from the Data Tables database 230 and 0.0001, for example, to yield a calculated 
residual commissions component. The software controlling operation of the Calculator 234 may 
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conduct this calculation. The equation may be in the software code. The calculated residual is 
then compared to the value in the Capamount field. If the calculated residual is less than the 
Capamount, the calculated residual is stored. If the calculated residual is greater than the 
Capamount, then the Capamount is stored. 

[0089] If the age of the account is 5 months, for example, the Bpts_year is 1. "A" is set 

in the CHK Table field, indicating that the CMHSTAC table needs to be checked for 
qualification. The achievement level for month 5 is compared to the actual net sales. If the 
achievement level for month 5 is met, then the applicable basis points is identified in the 
RESDDBASISPNTS Table of Fig. 6, based on the Bpts_year 1 and the Start and End Dates of 
the approval (or activation) date of the merchant, as discussed above. Cap amount is checked, as 
well. If the achievement level is not met, no residual payments are made for this merchant 
account. 

[0090] If the age of the account in months is 14, for example, the Bpts_year is 2. "A" is 

set in the CHK_Table field, indicating that the CMHSTAC table needs to be checked for 
qualification for residuals. The achievement level for month 14 is compared to the net sales. If 
the achievement level for month 14 is met, then the applicable basis points is identified in the 
RESIDJBASISPNTS Table of Fig. 6, based on the Bpts__year 2 and the time period defined by 
the Start and End Dates of the critical date, as discussed above. Capamount is checked, as well. 
If the achievement level is not met, no residual payments are made for this merchant account. 
[0091] If the age of the account in months is 20, the flag in the CHK_Table field is set to 

Q, indicating that the RESQUAL table needs to be checked, to confirm that the achievement 
level was met in month 14, in this example. If it has, then the applicable basis points for month 
20 is identified in the RESID_BASISPNTS table in Fig. 5, based on the Bpts_year, which is still 
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2, and the time period of the critical date. Capamount is checked, as well. If the achievement 
level for month 14 has not been met, then no residuals are paid in month 20, either. 
[0092] The residual for each merchant account may be stored in a residual payment table 

(not shown) for that sales rep, in association with an identification of the merchant account, for 
example, in the Data Tables database 230 or in the memory 236. Calculated residuals for all the 
merchant accounts in the sales rep's portfolio may be similarly calculated and stored in the table. 
A sum of all the residuals may be calculated and stored in a residual field in a commissions 
component table (not shown), also in the Data Tables database 230 or in the memory 236. Other 
calculated commissions components for the sales rep may be stored in the commissions 
components table, and summed to yield the net calculated commissions components. 
Adjustments for the sales rep may be similarly calculated, stored in an adjustments table, 
summed and then offset against the net calculated commissions to yield the adjusted calculated 
commissions for that sales rep. The adjusted calculated commissions for all sales reps may be 
stored in one or more tables, as well, associated with an identification of the sales rep and the 
time period, for example. The calculations may be performed by the Calculator 234, for 
example. Tables discussed here and other portions of the description and not shown, may be 
readily constructed by those skilled in the art. 

[0093] Fig. 7 is an example of a method 400 of incorporating business rules in tables in 

accordance with an embodiment of the invention. A business rule is received from an Alliance, 
in Step 402. The business rule may be the basis points used to calculate a commissions 
component, for example. The business rule is stored in a table, in Step 404. A change to a 
business rule already stored in a table is received from the Alliance, in Step 406. The change is 
made to the business rule in the table, in Step 408. A new business rule is received from an 
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Alliance, in Step 412. The new business rule is added to a table, in Step 414. These steps may 
take place in different orders, as well. Business rules may be entered and modified via an 
interface device 248 to the processor 120, for loading into the Business Rules Tables database 
232, for example. The interface 248 may be a computer, for example, comprising a keyboard 
and a display (not shown). 

[0094] These tables are merely exemplary. Other tables with different information may 

be used in accordance with the teachings of the present invention, as is apparent to one of 
ordinary skill in the art. In addition, the particular business rules established by Alliances or 
other such third parties may dictate the use of different tables. 

[0095] As discussed above, storing the business rules in tables instead of in program code 

facilitates the entry and change of business rules. This is particularly useful in systems servicing 
a large number of Alliances, each of which may have unique, multiple plans, which may be 
modified often. The embodiments of the invention would be useful in simpler systems, as well. 
[0096] Other Commissions Calculating Systems may use some or all of this type of 

information and other information, dependent upon the environment the system is used in (type 
of business, for example) and the particular details of the commission payment plans being 
implemented. While the CCS System 100 has been described above in the context of the credit 
and debit card industry, such a system may be used in any industry where commissions are paid, 
particularly where commissions are paid in accordance with a multiplicity of variable business 
rules. In addition, while described above with respect to a system hiring sales reps to represent 
Alliances 15, embodiments of the invention are applicable to systems hiring sales reps to 
represent any third party or to represent the system itself. The system and third parties may be 



30747320.DOC 



35 



involved in card processing, other financial transactions, or the sale of any types of products and 
services, whether financial or not. 

[0100] The systems disclosed herein are in a form in which various functions are 

performed by discrete functional blocks. However, any one or more of these functions could 
equally well be embodied in an arrangement in which the functions of any one or more of those 
blocks or indeed, all of the functions thereof, are realized, for example, by one or more 
appropriately programmed processors. 

[0101] The foregoing merely illustrates the principles of the invention. It will thus be 

appreciated that those skilled in the art will be able to devise numerous other arrangements 
which embody the principles of the invention and thus are within the spirit and scope of the 
invention, which is defined in the claims, below. 



30747320.DOC 



36 



